Enforce Java 11 response body timeouts - #3462

Good problem to solve — the Java 11 client genuinely ignores readTimeout once headers arrive, and I like that you covered both the sync and async paths with tests. Two things need fixing before this can go in.

1. Subclass overrides of toFeignResponse are silently bypassed

execute() now calls the new private three-arg toFeignResponse(Request, HttpResponse, Options). The existing protected Response toFeignResponse(Request, HttpResponse) is left in place but is no longer on the execution path — so any subclass overriding it (a documented extension point today) keeps compiling and keeps passing its own tests, while its code stops being called in production. That's the worst kind of breaking change: invisible.

Http2ClientContentLengthTest hides this, because it calls the two-arg form directly and therefore exercises a path production no longer uses.

Please make the three-arg overload protected and reduce the two-arg one to a delegating shim (return toFeignResponse(request, httpResponse, null);), so overriding either signature still works.

2. One scheduled task per read() call

readWithTimeout schedules a ScheduledFuture and cancels it on every invocation, including the single-byte read(). For a consumer reading unbuffered, that's a schedule+cancel round-trip on a shared single-threaded executor per byte. Two allocations of AtomicBoolean per byte on top.

Schedule one deadline for the stream (or at least per read(byte[], int, int) batch) and check remaining time, rather than arming a fresh timer per read.

Smaller notes

• TimeoutInputStream doesn't delegate skip, mark, reset, markSupported. InputStream#skip routes through read, so it's correct, but markSupported silently degrades to false for a delegate that supported it.
• BODY_READ_TIMEOUT_EXECUTOR is a process-wide static that's never shut down. Daemon thread makes that survivable, but it means every Http2Client in the JVM shares one timer thread — worth a comment at minimum.
• In readWithTimeout, the throw timeoutException == null ? timeoutException(e) : timeoutException; line reads awkwardly. if (timeoutException != null) throw timeoutException; throw timeoutException(e); is clearer.
• Please make sure the new tests use Retryer.NEVER_RETRY consistently — the async one doesn't set it, so a retry would multiply the 1s body delay.